NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part1/729

Internet Message Format | 1996-08-06 | 5.7 KB

Path: news.cyberport.com!usenet
From: [e-mail] (Warren Young)
Newsgroups: comp.lang.c++
Subject: Re: Hungarian notation
Date: Sat, 06 Jan 1996 17:31:21 GMT
Organization: Kennedy and Associates
Message-ID: <4cmblb$[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <4c44dh$[e-mail]> <4c477m$[e-mail]> <4ccq2u$[e-mail]>
NNTP-Posting-Host: ppp3.cyberport.com
X-Newsreader: Forte Free Agent 1.0.82

[e-mail] wrote:

>In <4c477m$[e-mail]>, [e-mail] (Warren Young) writes:
>>[e-mail] wrote:

>>Sure the semantics change.  Try passing the latter to printf() and see
>>how broken the program gets.  Or strlen(), or strtou()...  Granted,
>>you're likely to be changing the string manipulation functions at the
>>same time, but this is one place where HN becomes useful: helping you
>>find the places where you missed a function call that needs changing.

>In all of the cases, except printf(), the function prototypes (everyone
>uses those, right?) will catch any type change which is incorrect.  And

Of course.  These were merely examples of well-known functions where
passing the new string would cause problems.  You asserted that the
semantics didn't change, and I just dashed off some examples that
disproved that.

>printf() is kinda obsolete.  If you are dealing with wide character types
>you are almost certainly not going to be using printf().

Your example was converting an existing "standard" string into a wide
character string by prefixing it with L.  So, it's very likely that
the original program was using something that wanted regular strings,
and the change will probably stop it working from right.

>But, even if you
>were, a global grep for printf / "insufficientStorage" would catch all of
>those combinations.  So Hungarian notation doesn't buy you much here.

Sure, you can do the compile-and-grep thing until it finally compiles,
but this method can fail you, because of the usages can be missed.
Between strong type checking, lack of vararg functions and careful
coding habits, you can be assured that the compiler will catch most of
the problems, but it's always those little things that the compiler
thought were copacetic that get you.

If you're using HN, you will be _forced_ to visit every usage of that
variable.  If you care enough about types to be using a
well-considered HN variant (I'm not talking about that Petzoldian
alphabet hash), you'll probably take the opportunity to make sure that
the semantics are still OK.  I know of no better way of encouraging
this than HN.

>Type safefty is available in the language.  Those who don't use it get
>what they deserve.

I agree, and if this is heeded religiously, it completely solves type
compatibility problems for C++ houses.  In other, less perfect
environments, such as C-only houses and those where you can't count on
everyone to follow the rules, HN is useful.  HN also has another
mission, and that is to encourage programmers to consider semantic
issues more carefully, especially in cases where the code mixes types
and yet compiles without warning.  Your rule does nothing in this
regard.

Don't think that I have HN pinned down, though.  I've recently been
refining my HN variant, and with this thread, I have a whole list of
style and usage questions that I want resolved in my version of HN.
Once this thread starts dying (or at least stops giving me questions
to answer), I hope to start on a semi-formal definition of my HN
variant, which I may post.

>>>The use of upper case names to distinguish #define names is one
>>>of the worst pseudo-standards that have been fostered upon the
>>>programming community.  Right up there with Hungarian notation.
>>
>>It's very useful with macros, because it tells the reader, "Hey!  The
>>arguments to this macro aren't type-safe and there may be
>>side-effects!"  With C++, though, I have a solution that both of us
>>might find acceptable: dump #defines for consts and inline functions.

>... if you have very many global constants
>the use of const data elements can add a LOT of space to the
>compiled program.  Not always acceptable.  With #defines and
>constant folding in the compiler/linker that is less of a problem.

The only excuse I can think of for not having constant folding turned
on is if your code is taking and using the address of a constant.  If
you're doing that, though, you have no sense of style anyway.
(Whether by your choice or Fate's, the result is the same.)

>And macro functions are still useful -- although much less frequently
>than in the past.  I have used them to "map" a common function to
>different operating systems.  Here, even the inline template function
>doesn't work well.  Further, the code is reduced since the alternate
>operating system code goes away at compile time.  An example of

It goes away with inline functions, too, becase you're likely to be
using conditional compilation to switch the various versions of the
inline wrapper in and out.  _I_ would be, anyway....

>Another example was the use of printf() in some
>C code.  It turns out that the Microsoft compiler didn't support printf()
>in the library for some types of programs, but you could call a system
>wprintf() to do the same thing (with restricted types, but that was

Yes, where you essentially need compile time search and replace,
#defines are useful.  Since you can't wrap a vararg function with an
inline wrapper (or even a proper #define macro (one with arguments)),
you simply have to replace the function name at compile time.  That's
about it, though.

= Warren --